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The  Remote  Atmospheric  Probing  Information 

Display  (RAPID)  System 


1.  INTRODUCTION 

The  Air  Force  Geophysics  Laboratory  (AFGL)  is  developing  the  capability  for 
accurate  nowcasting  of  cloud  and  precipitation  for  use  in  support  of  general  air  and 
terminal  operations  as  well  as  communication  activities.  RAPID  is  a  system  for 
generation  of  such  forecasts  (0  to  0.  5  hr)  through  the  use  of  continuously  updated 
radar  and  satellite  data.  The  underlying  premise  of  the  forecasting  methodology 
is  that  future  distributions  of  precipitation  may  be  derived  from  monitoring  and 
forecasting  patterns  of  selected  precipitation  intensity. 

This  effort  is  part  of  a  larger  initiative  to  develop  a  multifaceted  system  to 
provide  0  to  2  hr  forecasts  of  cloud  and  precipitation.  The  more  comprehensive 
effort  will  also  include  prediction  of  cloud  development  through  detection  of  storm 
development  precursors.  Although  the  system  described  here  is  for  the  0  to  0.  5  hr 
forecast  effort,  it  has  sufficient  flexibility  to  allow  for  expansion  into  more  exten¬ 
sive  forecasting  tasks. 

One  element  addressed  in  the  development  of  RAPID  involved  system  hardware 
and  software  and  how  they  could  provide  an  efficient  environment  that  encourages 
user  participation.  A  second  element  concerned  development  of  data  analysis 
techniques  and  associated  software  to  operate  within  this  environment.  This  re- 
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port  will  focus  on  the  system  hardware  and  environment  definition,  while  a  second 
report  by  Bohne*  addresses  technique  development. 

2.  SYSTEM  REQUIREMENTS 

Before  a  specification  of  the  system  components  could  be  derived,  it  was  nec¬ 
essary  to  assess  the  hardware  environment  desired.  Numerous  factors  were  con¬ 
sidered:  including  hardware  and  data  concerns,  the  desired  operational  forecast¬ 
ing  environment,  the  needs  of  potential  users,  and  the  lack  of  computer  support 
personnel.  From  these  considerations,  it  was  determined  that  the  system  hard¬ 
ware  must  be: 

off-the-shelf,  that  is,  requiring  no  development  of  unique  hardware  compo¬ 
nents; 

easy  to  install  and  maintain; 

supportive  of  a  mature  and  robust  operating  system  having  real-time  capabil¬ 
ity; 

of  sufficient  processing  power  to  allow  for  processing  large  data  sets  in  real¬ 
time; 

reliable; 

cost  effective,  that  is,  the  lowest  priced  system  to  meet  all  the  requirements; 

expandable  to  allow  for  growth. 

In  addition,  the  software  environment  generated  by  the  selected  hardware 
must  be: 

capable  of  handling  large  data  sets  (12  to  24  Mbytes); 

user  friendly  and  supportive  of  data  storage  and  file  standardization  proce¬ 
dures; 

supportive  of  software  development  in  higher  level  languages  (for  example, 

"C"  and  FORTRAN); 

supportive  of  a  file  management  architecture  that  allows  for  hierarchical 
structuring  of  files; 

sufficiently  flexible  to  allow  a  variety  of  uses; 

supportive  of  real-time  operation. 

The  RAPID  system  methodology  is  intended  to  include  all  processes  from  data 
ingestion  to  the  generation  and  display  of  the  short-term  forecasts.  It  was  deter¬ 
mined  that  data  acquired  from  remote  sensors  should  first  undergo  preliminary 
coordinate  conversions  on  other  systems.  It  was  also  anticipated  that  RAPID 
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should  be  capable  of  eventually  incorporating  other  short-term  forecast  ap¬ 
proaches  such  as  the  use  of  simple  numerical  models. 

With  these  considerations  in  mind,  the  components  and  associated  require¬ 
ments  considered  essential  for  the  system  are: 

1.  A  host  system 

--with  general  purpose  processor(s)  of  sufficient  speed  and  memory  to 
process  large  amounts  of  data  and  to  allow  for  manipulation  of  multiple 
images; 

--with  enough  disk  storage  to  allow  for  several  test  data  sets  (typically, 

12  Mbytes  per  set)  as  well  as  system  and  user  applications  software. 

2.  An  image  processor  with  sufficient  memory  to  store,  manipulate,  and 
display  multiple  images. 

3.  Communication  links 

--between  RAPID  and  other  hosts  that  allow  minimum  data  rates  of  9600 
bits  per  second  for  the  transfer  of  satellite  and  radar  images; 

--between  the  display  and  host  allowing  high  speed  data  transfer  via 
Direct  Memory  Access  (DMA). 

The  resultant  system  satisfied  the  above  considerations.  It  should  be  noted, 
however,  that  the  actual  process  of  design  was  more  evolutionary  than  might  be 
apparent  here.  Where  appropriate,  some  of  this  evolution  of  thought  will  be 
briefly  discussed  to  more  completely  present  the  RAPID  system  concept. 

3.  SYSTEM  DESCRIPTION 

Within  any  computer-based  system,  there  are  both  hardware  and  software 
elements.  While  it  is  difficult  to  separate  these  in  many  cases,  the  following  dis¬ 
cussion  attempts  to  preserve  this  distinction. 

3. 1  System  Hardware 

As  outlined  earlier,  the  RAPID  system  may  be  described  as  having  three  ma¬ 
jor  hardware  elements.  The  overall  configuration  of  the  assembled  system  is 
shown  in  Figure  1,  and  the  specific  element  attributes  are  discussed  in  the  follow¬ 
ing  sections. 

3.  1.  1  HOST  COMPUTER 

Digital  Equipment  Corporation  (DEC)  hardware  was  chosen  for  the  host  sys¬ 
tem  because  it  best  satisfied  all  of  the  stated  requirements.  In  particular,  DEC 
systems  were  easy  to  install,  required  no  special  hardware  development  to  allow 
integration  of  other  components,  and  fulfilled  all  software  requirements.  Initially, 
a  DEC  VAX  11/750  served  as  host  to  the  RAPID  system.  It  had  4  Mbytes  of  mem- 


<u 


TCP/IP  Radar 

"■■■  VAX 

, - 1  I/75C 


DECnet 


AIMS 
VAX  ' 
1/750, 


DECnet 


GOES 

Ground 

Station 


AIMS 

SEL 

32/27 


AIMS 
Micro 
Vox  II 


DECnet 


Micro 

VaxH 


DECnet 


a  Micro 
p  Vox! 


DECnet 


/Graphic 


Tablet 


\[d 

r 

Adage 

A _ I _ / 

—  Color 

A)  ip 

Image 

Monitor 

i-y  i _ 

r 

Procesior 

Figure  1.  Schematic  Representation  of  Processing  Hardware  and 
Communication  Links  Pertaining  to  the  RAPID  System.  Hardware  in 
center  right  are  part  of  AFGL  AIMS,  while  that  below  constitutes 
RAPID.  Hardware  in  the  upper  left  is  located  at  the  AFGL  radar  fa¬ 
cility  in  Sudbury.  Dotted  lines  indicate  RAPID  configuration  in  initial 
developmental  stage. 
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ory,  a  456  Mbyte  disk,  1600  bpi  tape,  and  all  standard  terminals  and  I/O  devices 
attached.  It  also  had  a  synchronous  serial  line  that  connected  RAPID  to  the  AFGL 
Interactive  Mcldas  System  (AIMS)  VAX  at  Hanscom  Air  Force  Base.  The  above 
equipment  is  located  at  the  AFGL  Ground-Based  Remote -Sensing  Site  (LYR)  in 
Sudbury,  Mass. 

Subsequently,  the  RAPID  system  has  been  relocated  to  the  AFGL  Hanscom 
AFB  site.  Currently,  a  DEC  MicroVAX  II  serves  as  the  RAPID  host  computer, 
and  the  ADAGE  image  system  has  been  transferred  to  this  new  host.  Figure  1 
shows  this  current  configuration  and  how  it  relates  to  the  original  system  config¬ 
uration.  The  new  RAPID  VAX  host  has  twice  the  memory  and  twice  the  perform¬ 
ance  of  the  original  host.  The  Sudbury  VAX  is  now  being  used  to  communicate 
radar  data  from  Sudbury  to  the  RAPID  System.  The  only  hardware  adjustment  re¬ 
quired  for  the  RAPID  relocation  was  a  new  DMA  controller  board  to  connect  the 
ADAGE  to  the  MicroVAX.  Since  hardware  expansions,  upgrades,  and  changes 
have  been  so  easily  accommodated,  the  validity  of  selecting  this  hardware  config¬ 
uration  has  been  verified. 

3.1.2  IMAGE  SYSTEM 

The  imaging  system  consists  of  the  ADAGE  RDS-3000  display  system,  moni¬ 
tor,  and  camera  (Figure  2).  Within  the  ADAGE  are  two  distinct  components:  a 
video  display  unit  and  an  embedded  bit-slice  processor  (BPS).  This  configuration 
allows  for  a  high  degree  of  parallelism  during  operations.  For  example,  while 
video  display  operations  from  display  memory  are  occurring,  the  same  memory 
can  be  independently  accessed  by  both  the  host  computer  and  the  embedded  BPS. 

Currently,  the  ADAGE  video  display  system  contains  8  Mbytes  of  image  mem¬ 
ory  allocated  into  two  "pages.  "  Each  page  is  organized  as  a  1024-  by  1024-(x,  y) 
pixel  plane  with  each  pixel  location  32  bits  deep.  Within  this  configuration,  any 
contiguous  pixel  block,  up  to  512  by  512  pixels,  is  viewable  at  a  60Hz  refresh 
rate,  and  each  pixel  is  addressable  via  its  (x,  y)  coordinates.  In  addition,  each 
page  may  be  thought  of  as  32  single-bit  planes  of  1024  by  1024  pixels.  Images  can 
stored  on  any  single  or  contiguous  combination  of  bit  planes,  thereby  allowing  the 
storage  of  multiple  images  of  varying  depth  (for  example,  1,  2,  3,  etc.  bits  deep) 
in  one  (x,  y)  region. 

To  view  images,  the  data  are  first  written  to  the  image  memory  by  either  the 
ADAGE  BPS  or  the  host  computer.  A  512-  by  512-pixel  32-bit  image  can  be  writ¬ 
ten  (or  read)  in  approximately  3  sec.  While  the  ADAGE  employs  a  32-bit -wide 
data  bus,  the  user  can  control  which  of  the  32  bits  are  accessed  in  memory. 

From  the  video  memory,  the  image  data  goes  to  the  frame  buffer  controller  (FBC) 
where  software  parameters  select  the  viewing  window  location,  size,  aspect  ratio, 
and  magnification.  From  the  FBC,  the  image  data  passes  to  the  crossbar  switch 
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Figure  2.  Schematic  Representation  of  the  ADAGE  Image  Processor  and  the  Data 
Flow  From  Ingestion  to  Final  Display 


(XBS)  where  the  bits  or  bytes  to  be  viewed  are  software  selected  via  a  masking  op¬ 
eration.  From  the  XBS,  the  video  data  go  to  the  red,  green,  and  blue  color  look¬ 
up  table  memories  and  video  output  circuitry  (LUVO).  Incoming  data  values  point 
to  locations  in  the  color  tables  to  generate  th».  colors  and  shades  desired.  Although 
it  is  possible  to  display  over  sixteen  million  different  colors  (full-color  operation), 
the  current  configuration  employs  256  colors  for  both  display  and  overlay.  This 
flexibility  in  data  storage  (1  to  32  bits  of  storage  per  pixel)  and  display  are  major 
strengths  of  the  system. 

The  ADAGE  BPS  is  used  in  data  and  display  manipulation  by  acting  as  a  co¬ 
processor  under  the  control  of  the  host.  The  host  loads  routines  to  be  executed 
into  the  microcode  memory  (64  kbytes),  which  then  sends  the  microcode  instruc¬ 
tions  to  the  BPS  via  a  separate  instruction  bus,  and  then  monitors  the  coprocessor 
for  completion  of  the  routine.  These  instructions  are  generated  on  the  VAX  with  a 
"C  "  language  cross-compiler  to  produce  the  required  microcode.  Because  the 
BPS  can  execute  multiple  operations  concurrently  (for  example,  read  pixel,  shift 
and  mask,  and  conditional  test  operations),  it  has  a  distinct  speed  advantage  over 
the  host  processor.  Also,  since  the  BPS  is  general  purpose,  it  is  much  easier  to 
use  and  more  flexible  than  other  imaging  systems  that  are  more  algorithm  specific. 


On  the  other  hand,  algorithm-specific  hardware  is  usually  more  efficient  for  their 
designed  tasks. 


3.1.3  COMMUNICATION  LINKS 

There  are  two  external  and  one  internal  major  communication  links  required 
for  RAPID  operation: 

AIMS  to  RAPID  for  ingestion  of  satellite  data 

PE3242  to  RAPID  for  ingestion  of  radar  data 

VAX  to  ADAGE 

The  AIMS  to  RAPID  link  was  first  accomplished  by  means  of  9600  baud  tele¬ 
phone  lines  and  the  use  of  DECnet.  With  the  relocation  of  the  RAPID  system  to 
Hanseom  AFB,  the  AIMS  to  RAPID  link  was  altered  to  that  of  an  ETHERNET, 
where  AIMS  and  RAPID  are  all  part  of  a  Local  Area  V  AX  Cluster  (LA VC). 

The  transmission  of  radar  data  to  RAPID  in  the  original  LYR  configuration 
was  accomplished  by  first  preprocessing  the  data  on  the  LYR  Perkin  Elmer  3242 
minicomputer  and  then  passing  it  to  the  RAPID  VAX  hos  via  an  ETHERNET  LAN 
(Local  Area  Network).  Other  methods  for  data  transfer  were  also  investigated, 
such  as  the  radar  processor  to  VAX  or  radar  processor  to  ADAGE.  In  both  in¬ 
stances,  however,  in-house  construction  of  specialized  hardware  would  have  been 
required.  The  networking  solution  adopted  required  only  the  purchase  of  proven, 
off-the-shelf  equipment.  With  relocation,  the  original  ALMS  to  RAPID  link  via 
telephone  has  also  been  inserted  to  complete  the  communication  from  the  PE3242 
to  RAPID  via  the  AFGL  Sudbury  Site  VAX. 

The  VAX  and  ADAGE  have  been  linked  through  the  acquisition  of  DMA  control¬ 
ler  boards  and  associated  software  for  the  VAX  systems.  This  allows  the  rapid 
two-way  communication  between  these  two  systems  necessary  for  the  efficient 
sharing  of  large  volumes  of  data.  As  already  noted,  this  was  the  only  hardware 
replacement  required  to  accommodate  the  change  in  host  computers. 

3.2  System  Support  Software 


On  the  RAPID  system,  the  software  is  broken  into  two  large  bodies,  purchased 
software  packages  (to  control  general  machine  operations,  data  transfer  links,  and 
utility  functions)  and  user-developed  software.  User-developed  system  routines 


for  use  in  the  overall  RAPID  forecasting  program  are  termed  RAPID  software. 
This  class  of  software  is  discussed  in  Sections  4  and  5. 

The  purchased  packages  are  naturally  maintained  as  separate  entities  on  the 
VAX  system  and  require  no  organizational  considerations  from  the  standpoint  of 
disk  utilization.  This  software  is  loosely  identified  as  support  software.  As  in 
the  discussion  of  hardware,  the  system  support  software  may  also  be  discussed 
with  respect  to  the  three  main  system  components.  All  of  the  software  is 


mm m 


HWIHB 


resident  on  the  host  computer.  The  subdivision  here  simply  allows  for  clearer 
identification  of  the  applications. 

3.2.  1  HOST  SYSTEM  SUPPORT  SOFTWARE 

The  lack  of  computer  support  personnel  has  been  a  major  factor  influencing 
system  development  decisions.  With  software  the  first  user  interface  to  the 
RAPID  system,  selection  of  an  operating  system  and  software  development  envi¬ 
ronment  was  the  first  task.  A  UNIX -based  system  was  considered  but  was  judged 
not  viable  for  a  real-time  operating  system  nor  robust  enough  to  be  managed  by 
non-computer  science-oriented  personnel.  Alternatively,  DEC'  VMS  (Virtual 
Memory  System)  was  adopted,  for  it  provided  the  required  real-time  capability, 
simply  system  management,  and  suitable  software  development  environment.  The 
support  software  include  such  items  as  DEC  VMS  operating  system,  FORTRAN 
and  C  compilers,  and  DECnet  for  VAX-to-VAX  data  communications. 

3.2.2  IMAGE  SYSTEM  SUPPORT  SOFTWARE 

Commercial  software  was  acquired  to  allow  for  easy  and  flexible  interaction 
with  the  ADAGE  image  system.  In  particular,  ICROSS-3000  (the  cross-compiler 
that  creates  ADAGE  microcode  from  "C")  and  Adage-3000  FSS  (FORTRAN-sup- 
ported  graphics  subroutines  in  support  of  the  ADAGE)  have  been  acquired  and  are 
extensively  used  in  application  software.  The  ICROSS  software  allows  the  pro¬ 
grammer  to  develop  software  for  the  ADAGE  BPS  in  a  high-level  language,  there¬ 
by  enabling  improved  productivity  and  more  effective  use  of  the  ADAGE  processor. 
The  FSS  software  consists  of  FORTRAN  callable  routines  to  perform  manipulation 
of  display  parameters  (such  as  pan,  roll,  scroll,  etc. )  and  the  drawing  of  simple 
geometric  primitives.  These  FSS  routines  also  produce  microcode  that  is  down¬ 
loaded  into  the  ADAGE  BPS. 

3.2.3  COMMUNICATION  LINK  SUPPORT  SOFTWARE 

Communication  software  is  required  to  manage  the  interaction  between  the 
various  computer  systems.  For  the  ETHERNET  communication  link  between  the 
AFGL  Sudbury  PE  3242  and  VAX  11/750,  HYPER-Link  software  was  acquired. 

This  link  uses  the  DoD  network  communication  protocol  known  as  TCP/IP  (Trans¬ 
mission  Control  Protocol/Internet  Protocol).  Within  this  protocol,  all  information 
transfers  are  broken  into  sequences  of  small  messages  known  as  packets.  Pack¬ 
ets  are  transmitted  over  the  ETHERNET  hardware  and  reassembled  into  the  ori¬ 
ginal  message. 

DECnet  software  was  acquired  from  DEC  for  the  AFGL  Sudbury  VAX-to- 
AFGL  AIMS  link,  and  the  current  AlMS-to-RAPID  link  utilizes  LAVC,  another 
DEC  software  package. 


1.  THE  RAPID  ENVIRONMENT 


In  the  development  of  a  RAPID  working  environment  that  facilitates  both  soft¬ 
ware  development  and  is  conducive  to  the  operation  of  a  real-time  forecasting  sys¬ 
tem,  it  has  been  necessary  to  adopt  certain  practices  concerning  software  devel¬ 
opment  and  file  and  data  management.  These  are  intended  to  make  the  best  use  of 
the  system  hardware  and  RAPID  system  software.  The  most  pertinent  practices 
that  have  been  adopted  are  addressed  below. 

1. 1  Software  Standardization 

Software  standardization  procedures  are  rigidly  maintained  for  all  user-devel¬ 
oped  software.  Some  examples  include  use  of:  "RAPID  tools"  wherever  possible, 
structured  code,  extensive  documentation,  a  standard  comment  header  format  for 
ail  source  files,  and  standard  data  file  headers.  An  example  of  a  source  file  head¬ 
er  is  shown  in  Figure  3.  This  header  format  provides  a  history  of  program  evolu¬ 
tion,  various  argument  terms,  and  an  explanation  of  how  and  when  to  use  the  rou¬ 
tine.  Its  use  allows  efficient  maintenance  of  a  system  library  file  in  which  all 
RAPID  system  file  headers  are  stored.  Reference  to  this  library  allows  a  quick 
determination  of  the  availability  of  particular  system  tools.  These  procedures  are 
designed  to  reduce  duplication  of  effort  by  requiring  commonality  among  all  user- 
developed  software. 

4.2  RAPID  Software  Tools 

To  streamline  the  software  development  process,  the  concept  of  software  tools, 
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an  outgrowth  of  a  philosophy  developed  by  Kernighan  and  Plauger,  was  invoked. 

As  applied  here,  this  means  the  development  of  a  set  of  general-use  system  rou¬ 
tines.  Typically,  these  are  derived  from  user  routines  after  they  are  thoroughly 
tested  and  documented  according  to  the  specific  documentation  standard.  With  this 
procedure,  software  development  becomes  more  efficient  and  the  mechanics  of  in¬ 
dividual  programs  are  more  easily  understood.  Examples  of  such  common  tasks 
include  the  processing  and  analysis  of  satellite  and  radar  data,  the  loading  of  color 
tables  into  the  ADAGE,  and  reading  from  and  writing  to  ADAGE  display  memory. 
Much  of  this  software  is  located  in  object  libraries  that  are  assigned  when  a  user 
logs  into  the  system,  allowing  for  automatic  access  from  any  program  at  link  time. 


2.  Kernighan,  B.W. ,  and  Plauger,  P.  J.  (1976)  Software  Tools.  Addison-Wesley, 
Reading,  Mass. 
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NOTES: 
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CODED  VAX/VMS  FORTRAN  V4.3 


Figure  3.  Example  of  the  Source  File  Header  Adopted  for  Use  With 
All  RAPID  System  and  User  Files  for  Locally  Developed  Software 


4.3  File  Organization  on  the  VAX  Disk 

The  VAX  disk  is  organized  to  allow  users  access  to  data  and  programs  in  a 
logical,  simple,  and  expedient  manner.  The  physical  disk  is  divided  into  several 
"logical"  or  virtual  disks,  where  each  logical  disk  is  simply  a  top-level  (root)  di¬ 
rectory  with  a  functionally  oriented  name  (DATA,  ANALYSIS,  DISPLAY,  CONVER¬ 
SION,  or  UTILITY).  All  user-developed  system  files  are  similarly  categorized 
and  placed  in  the  corresponding  system  logical  disks.  When  implemented,  this 
gives  users  the  look  and  feel  of  having  several  smaller  disks  connected  to  the  sys¬ 
tem.  Additionally,  the  system  directories  kre  divided  into  subdirectories,  each 
subdirectory  containing  closely  related  files  that  logically  fall  under  the  associated 
"root"  directory. 


kl  Data  File  Headers 


The  processes  of  VAX  disk  organization  and  software  standardization  naturally 
led  to  consideration  of  data  management  requirements  for  image  data.  Throughout 
the  processes  of  software  development  and  testing  and  in  real-time  operations, 
large  quantities  of  satellite  and  radar  data  and  numerous  derived  products  will  be 
processed  within  RAPID.  For  efficient  data  transfer  and  storage,  a  standard 
image  data  file  format  was  developed  for  all  data,  regardless  of  sources.  Data 
files  consist  of  2 56 -byte  image  headers  paired  with  variable  size  data  sets.  The 
reason  for  having  such  a  global  standard  format  is  to  allow  general  purpose  soft¬ 
ware  (RAPID  tools)  to  be  written  to  read /write /display  all  local  data  without  re¬ 
gard  to  its  type. 

1.5  Dala  Management  Within  ADAGE  Display  Memory 

The  requirement  for  very  fast  and  efficient  processing  of  the  satellite  and  ra¬ 
dar  image  data  demands  processing  these  data  within  the  ADAGE  BPS.  This  re¬ 
sults  from  the  higher  speed  of  the  ADAGE  coprocessor  over  the  VAX  and  the  mini¬ 
mization  of  the  number  of  data  transfers  between  the  ADAGE  and  VAX  subsystems. 
Maintaining  data  resident  within  the  ADAGE  with  minimal  confusion  has  led  to  the 
allocation  of  specific  areas  of  display  memory  for  specific  types  of  data,  a  proce¬ 
dure  locally  termed  "memory  mapping."  In  this  manner,  the  various  types  of  re¬ 
motely  sensed  data  are  unambiguously  stored  and  information  about  these  data  is 
maintained  in  the  "file  cabinet,  "  an  area  set  aside  to  store  important  attributes  of 
these  data  fields. 

The  allocation  of  data  storage  in  ADAGE  memory  is  determined  primarily 
from  the  data  update  rate,  the  total  field  of  coverage  desired,  and  the  data  resolu¬ 
tion.  For  example,  a  complete  volume  of  radar  data  is  collected  every  5  to  10 
minutes,  from  which  are  constructed  three  horizontal  planes  corresponding  to  low, 
middle,  and  upper  layers  of  the  storm.  These  three  planes,  as  prescribed  by  the 
user,  provide  a  fairly  complete  description  of  the  three-dimensional  precipitation 
structure.  Satellite  data,  on  the  other  hand,  yield  one  visible  and  one  infrared 
image  every  30  minutes.  Therefore,  there  will  be  4.  5  to  9  times  as  many  radar 
images  as  satellite  images. 

If  we  refer  to  an  (x,  y)  portion  of  memory  (32  bits  deep)  reserved  for  data 
storage  as  a  frame,  there  is  a  simple  and  logical  system  of  data  storage.  Within 
each  radar  data  frame,  the  three  planes  (each  8  bits  deep)  of  data  derived  from 
one  radar  volume  scan  may  be  stored.  The  remaining  8  bits  may  then  be  reserved 
for  overlays.  For  satellite  data,  it  is  convenient  to  store  three  successive  images, 
each  8  bits  deep,  in  one  satellite  data  frame.  There  will  then  be  separate  frames 
for  infrared  and  visible  images. 


I. 


The  resulting  configuration  is  shown  in  Figure  4,  where  each  labeled  area  is 
a  frame.  The  map  reserves  ten  frames  for  radar  images  for  storage  of  1  to  2 
hours  of  data,  depending  on  the  frequency  of  collection,  and  one  frame  each  for  vi¬ 
sible  and  infrared  images  for  storage  of  1  hour  of  satellite  data.  Generally,  radar 
data  are  stored  with  a  resolution  of  2  km,  while  satellite  infrared  and  visible  data 
utilize  resolutions  of  4  km  and  2  km,  respectively.  To  obtain  a  viewing  window  of 
512  by  512km  of  data,  frames  of  256  by  256  pixels  each  for  radar  and  visible  sat¬ 
ellite,  but  only  128  by  128  pixels  for  infrared,  are  required.  The  second  page  of 
display  memory  has  been  reserved  for  use  as  a  general  work  area. 
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Figure  4.  Memory  Mapping  for  the  ADAGE  Indicating  Sizes,  Locations,  and 
Contents  of  Frames 


The  RAPID  "file  cabinet"  was  developed  in  order  to  retain  within  the  ADAGE 
itself  the  type,  location,  and  attributes  of  all  data  currently  stored  in  display  mem¬ 
ory.  This  directory  can  be  accessed  by  programs  running  on  the  BPS  and  host  at 
anytime.  For  each  image  stored  in  display  memory,  there  is  an  entry  (256  bytes 
long)  in  the  same  byteplane  in  the  file  cabinet.  With  this  organization,  new  data 
may  be  automatically  directed  to  the  proper  storage  location,  and  analysis  pro¬ 
grams  running  in  the  BPS  need  only  search  the  resident  file  cabinet  to  locate  the 
pertinent  data  for  subsequent  analysis.  This  approach  should  aid  in  optimizing  the 
analysis  and  forecasting  processes  in  the  development  of  real-time  nowcasts. 

5.  RAPID  SOFTWARE 

RAPID  software  represents  system  programs  and  packages  developed  by  the 
users  locally  and  those  obtained  from  other  user  groups.  These  software  include 
a  large  variety  of  routines  ranging  from  pure  data  analysis  procedures  through 
utility  functions.  After  the  user  software  is  debugged,  tested,  and  fully  document¬ 
ed  according  to  the  standardization  guidelines  mentioned  earlier,  both  the  source 
and  object  code  are  migrated  from  the  user  directory  into  the  appropriate  function¬ 
ally  identified  RAPID  system  directory.  The  following  description  is  not  all-inclu¬ 
sive,  but  is  presented  to  highlight  the  more  significant  components. 

5.1  General  Purpose  Libraries 

The  development  of  functionally  oriented  object  libraries  is  one  facet  of  the 
software  standardization  program.  They  are  logically  assigned  as  default  link  li¬ 
braries  when  a  user  logs  into  the  system,  so  that  they  can  be  accessed  automatic¬ 
ally  from  any  program  at  link  time.  Object  libraries  now  existing  on  the  system 
include  the  following: 

ANALYSIS:  [PROD.  VAX]ANALYZE_ON_VAX.  OLB  includes  locally  written 
software  that  perform  data  analysis  in  VAX  memory.  For  example,  it  includes 
routines  that  locate  data  contours  and  extract  contour  boundaries,  describe  the 
contour  boundaries  in  terms  of  directional  chain  codes,  and  determine  basic  param¬ 
eters  such  as  the  relative  maxima  and  minima  or  the  center  of  area  of  a  contour 
given  its  chain  code,  or  the  (x,  y)  coordinates  of  the  point  for  a  given  code  of  the 
chain. 

UTIL:[IO]IOLEB.  OLB  includes  locally  written  software  that  performs  various 
I/O  functions  between  the  VAX  and  peripherals  including  disk,  tape,  and  the 
ADAGE  BPS. 

ANALYSIS:[PROD.  ADAGE]ANALYZE_ON_ADAGE.  OLB  includes  locally  writ¬ 
ten  software  that  performs  data  analysis  using  the  ADAGE  image  processor.  Ex- 


amples  would  include  routines  to  generate  a  contour  silhouette  or  outline  given  its 
chain  code,  to  filter  data  for  the  purpose  of  noise  removal  and  smoothing,  to  re¬ 
duce  or  replicate  displayed  data,  to  clear  the  display,  to  subtract  two  images,  to 
calculate  the  histogram  of  a  displayed  image,  etc.  Many  of  the  routines  in  this 
library  are  written  in  ICROSS. 

DISPLA  Y:[TOOLS]IK.  OLB  contains  locally  written  software  that  performs 
various  utility  functions  in  the  ADAGE.  This  includes  routines  that  set/get  regis¬ 
ter  values,  load  color  tables,  save/restore  display  memory  to/from  disk,  set  the 
crossbar  switch,  and  display  colors. 

UTIL:[MISC]DRA WLIB  contains  locally  written  software  that  performs  primi¬ 
tive  graphics  operations,  for  example,  line-drawing,  circle  and  ellipse  generation, 
and  character  generation  (three  fonts  available).  All  display  data  are  generated  in 
integer  or  byte  arrays  that  can  then  be  displayed  on  the  ADAGE  or  saved  to  disk  as 
needed. 

5.2  FTEST 

To  test  the  boundary  feature  algorithms,  an  interactive  software  package, 
FTEST,  was  developed.  FTEST  has  evolved  into  the  main  driver  for  the  RAPID 
system  forecasting  package  and  will  control  the  concurrent  display  and  analysis  of 
satellite  and  radar  data.  This  package  includes  the  routines  used  in  the  feature 
extraction  and  mapping  and  is  being  modified  to  include  the  forecasting  algorithms. 
Typical  routines  include  data  thresholding  and  filtering,  contour  extraction,  chain 
code  development  and  matching,  simple  exponential  and  one-parameter  linear 
trend  extrapolative  forecasting,  and  contour  reconstruction.  The  program  is  com¬ 
pletely  modular  and  menu-driven. 

5.3  SHOWS4T 

SHOWSAT  is  a  software  package  that  allows  manipulation  of  satellite  images 
interactively.  The  program  is  completely  modular  and  menu-driven  and  contains 
display,  processing,  and  analysis  routines.  While  it  was  originally  designed  for 
standalone  performance,  modifications  have  been  made  for  its  incorporation  into 
an  overall  RAPID  processing  package  built  around  FTEST. 

5.1  Hewlett -Packard  Plotter  Software 

Hard  copy  plots  may  be  obtained  through  use  of  the  Hewlett-Packard  7545  six- 
color  pen  plotter.  A  number  of  standardized  software  packages  have  been  devel¬ 
oped  for  plotting  line  graphs  and  data  contour  .features  on  gridded  or  non-gridded 
backgrounds.  Additional  software  has  been  written  for  use  with  chain  code  data, 
for  plotting  features  such  as  segments  of  chain  code,  and  time  sequences  of  chain 


code  boundary  segments.  These  plots  aid  greatly  in  analysis  of  data  and  in  the 
development  of  mapping  techniques.  In  addition,  presentation  software  packages 
are  being  developed  for  the  generation  of  multicolor  viewgraphs  and  other  presen¬ 
tation  materials. 

5.5  Demo  Program 

To  illustrate  the  concepts  and  work  being  performed  on  the  RAPID  system  and 
some  of  the  special  techniques  being  developed  at  the  site,  a  RAPID  demonstration 
program  was  written.  The  demo  program  is  menu-driven  and  provides  a  visual 
display  on  the  ADAGE  display  monitor. 

5.6  NCAR  Graphics 

A  graphics  package  was  acquired  from  the  National  Center  for  Atmospheric 
Research  (NCAR)  that  is  device-independent,  and  thus  can  be  used  to  produce 
graphics  on  the  ADAGE,  the  Hewlett-Packard  pen  plotter,  or  any  other  graphics 
device  that  is  obtained  in  the  future.  This  package  has  been  used  extensively  in 
data  contour  plotting  and  display. 

5.7  NCAR  Radar  Analysis  Package 

A  software  package  for  processing  radar  data  was  obtained  from  NCAR,  in¬ 
stalled  on  the  VAX,  and  the  graphics  output  was  interfaced  with  the  ADAGE.  Some 
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of  the  characteristics  of  this  package  are  described  in  Mohr  and  Vaughan,  Mohr 
4  5 

and  Miller,  and  Mohr  et  al.  Basically,  the  software  can  read  data  from  a  vari¬ 
ety  of  sources  (for  example,  NCAR  radars,  NOAA /NSSL  radars,  etc.),  convert 
them  to  a  common  format,  and  interpolate  the  data  to  a  rectangular  Cartesian 
grid.  The  resultant  fields  can  then  be  manipulated,  edited,  analyzed  statistically, 
and  combined  with  data  from  other  radars  to  produce  combined  products  like 
three-dimensional  wind  fields.  At  any  point,  a  variety  of  graphical  or  printed  dis¬ 
plays  are  available.  While  this  analysis  package  will  not  be  included  directly  in 
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trols,  Preprints,  21st  Conference  on  Radar  Meteorology,  American  Meteor- 
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the  RAPID  software  package,  it  has  proven  very  useful  in  generating  radar  Car¬ 
tesian  fields  for  testing  algorithms  and  as  a  model  for  the  real-time  interpolation 
package  developed  for  the  AFGL  Ground-Based  Remote  Sensing  Site's  Perkin  El¬ 
mer  computer. 

6.  DATA  FLOW  OVERVIEW 

With  the  hardware  and  software  elements  of  the  RAPID  system  clarified,  it  is 
useful  to  examine  the  data/product  flow  into  and  among  these  elements.  Figure  1 
shows  the  RAPID  system  linked  to  two  other  systems  from  which  radar  and  satel¬ 
lite  data  are  obtained.  The  Doppler  radar  data  is  received  from  the  AFGL  10  cm 
Doppler  radar  in  Sudbury,  Mass.  The  raw  radar  data  are  first  processed  in  the 
Doppler  radar  processor  resulting  in  a  final  output  data  rate  of  about  0.3  samples 
per  millisecond.  These  data  are  passed  to  the  PE  3242  minicomputer,  where  the 
reflectivity  factor  data  are  interpolated  to  a  Cartesian  grid  format.  The  resultant 
fields  are  transferred  to  the  Ground-Based  Remote  Sensing  Site  VAX  11/750  via 
ETHERNET.  Originally,  this  was  the  route  to  RAPID.  Currently,  these  data  are 
subsequently  shipped  to  the  AFGL  AIMS  VAX  cluster  via  DECnet  and  then  to  the 
microVAX  workstations  used  in  this  project.  This  procedure  makes  good  use  of 
the  Ground-Based  Remote  Sensing  Site  PE  3242  with  its  large  memory,  high  speed, 
and  large  disk  storage  capability,  significantly  reduces  the  data  flow  among  the 
various  nodes,  and  frees  the  RAPID  system  from  the  time-consuming  radar  data 
assimilation  task. 

Similarly,  data  are  received  by  the  RAPID  system  from  the  AIMS  VAX  cluster 
network.  AIMS  routinely  acquires  data  from  the  GOES  satellite  and  a  number  of 
standard  surface-based  weather  reporting  stations.  The  satellite  imagery  data 
are  "filtered"  within  AIMS  to  focus  on  the  area  of  interest  (roughly  a  512  by  512  km 
region)  centered  about  the  Sudbury  radar  location  prior  to  its  transmission  to  the 
RAPID  system. 

When  the  RAPID  host  receives  a  new  satellite  or  radar  image,  it  is  down¬ 
loaded  to  the  ADAGE  subsystem.  These  data  are  automatically  written  to  speci¬ 
fied  locations  in  the  ADAGE  display  memory  and  catalogued  in  the  ADAGE  "file 
cabinet. "  With  the  data  now  resident  within  the  ADAGE,  automatic  or  interactive 
processing  through  either  the  ADAGE  BPS  or  VAX  host  system  is  performed  and 
the  products  displayed  on  a  high-resolution  color  monitor.  These  data  may  also 
be  copied  to  the  host  disk  for  archiving. 

A  review  of  the  various  data  processing  and  analysis  procedures  adopted  in 
RAPID  may  be  found  in  Bohne  et  al.  *  Currently,  both  FTEST  and  SHOWSAT  are 
being  utilized  in  the  methodology.  Efforts  are  under  way  to  fine  tune  analysis 


routines  and  develop  a  real-time  executive  program  to  control  the  complete  data 
flow  from  radar  processor  through  display  of  final  forecasted  precipitation  field 
distri  ^tions. 

7.  SUMMARY 

The  RAPID  system  is  being  developed  as  a  tool  for  providing  short-term  fore¬ 
casts  in  real  time.  The  system  is  designed  with  the  philosophy  that  hardware  and 
software  should  be  easily  maintained  and  that  program  development  should  be  per¬ 
formed  within  a  user-friendly  environment.  In  terms  of  hardware,  this  has  re¬ 
sulted  in  the  acquisition  of  powerful,  user-friendly,  yet  versatile  off-the-shelf 
components:  a  Digital  Equipment  Corporation  VAX -based  computer  as  host,  and 
an  ADAGE  RDS-3000  for  image  processing. 

From  the  software  perspective,  this  philosophy  has  resulted  in  the  develop¬ 
ment  of  a  structured  programming  and  database  management  environment  that  re¬ 
sults  in  enhanced  maintainability  and  reliability.  Elements  of  this  environment 
include  a  functional  disk  organization,  program  and  subroutine  source  file  headers, 
common  database  management  routines,  common  interface  routines,  common  dis¬ 
play  routines,  and  a  well-established  calling  standard  for  display  system  manipu¬ 
lation.  The  result  has  been  the  development  of  an  environment  conducive  to  soft¬ 
ware  development  by  scientists  as  well  as  programmers. 

To  facilitate  real-time  operation,  a  number  of  steps  have  been  taken.  Radar 
and  satellite  data  are  preprocessed  6n  other  minicomputers  prior  to  shipment  to 
the  RAPID  host  computer.  These  data  are  downloaded  into  specially  allocated  re¬ 
gions  within  the  ADAGE  display  memory  where  approximately  2  hours  of  data  may 
be  stored.  The  major  portion  of  the  analysis  is  offlorded  to  the  high-speed  ADAGE 
coprocessor  to  act  on  data  resident  in  display  memory.  This  maximizes  the  ef¬ 
fectiveness  of  the  computationally  faster  image  processor  and  minimize*3  the  num¬ 
ber  of  data  transfers  between  computer  components.  Current  efforts  include  fine- 
tuning  routines  and  the  development  of  a  real-time  executive  manager  to  direct  all 
data  processing  steps  from  data  ingestion  through  final  forecast  product  display. 
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